Remote data facility over an IP network

ABSTRACT

A data storage system capable of performing remote data services (e.g., data mirroring) over an IP network using native connections to the IP network is described. The data storage system employs an architecture that manages the remote data services and the native connections to the IP network in a way that isolates the remote data services application software from the TCP/IP and lower level network processing.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority from U.S. Provisional PatentApplication Ser. No. 60/325,658, filed Sep. 27, 2001, incorporatedherein by reference in its entirety for all purposes.

BACKGROUND

[0002] The invention relates generally to data storage systems, and inparticular, to data storage systems with remote data mirroringcapability.

[0003] Given the importance of the availability of information, severaltechniques have been developed for providing enhanced reliability andavailability of data stored in a data storage system. Once suchtechnique is remote data mirroring. In a “mirrored” system, the datastored on one data storage system is replicated on another data storagesystem, preferably at a geographically remote site. Thus, if one or morestorage devices on one of the data storage systems fails, or acatastrophic system failure should occur, the data is readily availablein the form of a mirrored copy from the remote data storage system.

[0004] Devices on a data storage system (or source) that are mirrored onthe same remote, data storage system (or target) are referred to as adevice group. Likewise, devices on the target that serve or mirrordevices on the same source are referred to as a device group. Devicegroups are used, for example, to insure the consistency of blocks ofdata too large to be stored in a single area, during planned orunplanned interruptions such as link failures or planned back-ups.Device groups typically span a number of physical and logical volumes,and, in some instances, as when data striping is used, several devicegroups may be mapped to different portions of a physical or logicalvolume.

[0005] Typically, in a remote data mirroring environment, the source andtarget device groups are arranged as pairs on any two systems and thesource/target device group pairs are connected by dedicated data links(e.g., ESCON links) or switched data links (e.g., switched Fibre Channellinks). The data links support writes during data backup operations andreads during data recovery operations.

[0006] Such point-to-point and switched data link topologies havedistance limitations. To negotiate long distances, the ESCON (or FibreChannel) data links (connected to data ports of the data storagesystems, local and remote) are coupled via a leased line (such as T3) oran IP network. There are significant drawbacks associated with thesetypes of long distance solutions, however. For example, the T3 link isextremely expensive and very slow compared to the ESCON or Fibre Channellinks. In addition, because connections using these solutions spandiverse network protocols and interfaces, some type of adapter box mustbe used to translate between diverse protocols and interfaces of, say,ESCON and T3, or ESCON and IP. Typically, the adapter box is designed,configured and managed by some entity other than the data storage systemsupplier. This means that some aspects of the data storage system'sperformance are either dictated by the adapter box (for example, delaysdue to the buffer constraints or encapsulation, availability of IPservices), or the quality of the IP line, for example, an IP connectionprovided by an Internet Service Provider, and are therefore not withinthe control of the data storage system supplier. Moreover, the design ofthe adapter boxes, in particular, those supporting FC-to-IP services,can be quite complex, making networks of remotely-connected data storagesystems that employ such boxes expensive from a field serviceperspective.

SUMMARY

[0007] In one aspect, the invention provides methods and apparatus,including computer program products, for operating a data storage systemin a remote data mirroring arrangement of data storage systems. Themethods include determining that storage traffic is to be transferredbetween the data storage system and a remote data storage system towhich the data storage system is coupled by an IP network and enablingtransfer of the storage traffic between the data storage system and theremote data storage system over the IP network using a native connectionto the IP network.

[0008] Particular implementations of the invention may provide one ormore of the following advantages.

[0009] The present invention allows data storage systems in a remote,data mirrored configuration to participate directly as members of anduse the full set of services of an IP network. Allowing the data storagesystems to establish native connections to an IP network directlyeliminates the need for expensive third-party adapter boxes, which limitthe extent to which the data storage systems can use the services of anIP network. Moreover, because the adapter boxes are eliminated, a datastorage system supplier is able to better control and monitorperformance of remote data service functions that use an IP network(such as the Internet) for long distance transfer of storage traffic.

[0010] Other features and advantages of the invention will be apparentfrom the following detailed description and from the claims.

DESCRIPTION OF DRAWINGS

[0011]FIG. 1 is block diagram of a data processing system including hostcomputers coupled to a data storage system, which includes storagedevices coupled to a storage controller for controlling data transfersbetween the host computers and storage devices as well as between thedata storage system and another, remote data storage system.

[0012]FIG. 2 is a detailed block diagram of the data storage system andits storage controller (shown in FIG. 1), which includes a remote(Remote Data Facility or “RDF”) director for managing the exchange ofRDF storage traffic between the data storage system and a remote datastorage system over an IP network.

[0013]FIG. 3 is a block diagram of a remote, data mirrored arrangementof data storage systems (like the one depicted in FIGS. 1 and 2) thatare interconnected by an IP network (shown as the Internet) and arecapable of sending storage traffic to each other over the IP networkusing native connections.

[0014]FIG. 4 is a block diagram of a two-processor implementation of theremote director (of FIG. 2) to enable native connections to an IPnetwork.

[0015]FIG. 5 is a depiction of the software executed by the processorsin the remote director.

[0016]FIG. 6 is another block diagram of the remote director that showsdetails of a shared memory implementation for exchanging socketinterface messages across processor boundaries.

[0017] Like reference numerals will be used to represent like elements.

DETAILED DESCRIPTION

[0018] Referring to FIG. 1, a data processing system 10 includes hostcomputers 12 a, 12 b, . . . , 12 m, connected to a data storage system14. The data storage system 14 can be, for example, that made by EMCCorporation and known as the Symmetrix data storage system. The datastorage system 14 receives data and commands from, and delivers data andresponses to, the host computers 12. The data storage system 14 is amass storage system having a controller 16 coupled to pluralities ofphysical storage devices shown as disk devices 18 a, disk devices 18 b,. . . , disk devices 18 k. Each of the disk devices 18 is logicallydivided, in accordance with known techniques, into one or more logicalvolumes.

[0019] The controller 16 interconnects the host computers 12 and thedisk devices 18. The controller 16 thus receives write commands form thevarious host computers over buses 20 a, 20 b, . . . , 20 m,respectively, for example, connected and operated in accordance with aSCSI protocol, and delivers the data associated with those commands tothe appropriate devices 18 a, 18 b, . . . , 18 k, over respectiveconnecting buses 22 a, 22 b, . . . , 22 k. Buses 22 also operate inaccordance with a SCSI protocol. Other protocols, for example, FibreChannel, could also be used for buses 20, 22. The controller 16 alsoreceives read requests from the host computers 12 over buses 20, anddelivers requested data to the host computers 12, either from a cachememory of the controller 16 or, if the data is not available in cachememory, from the disk devices 18.

[0020] In a typical configuration, the controller 16 also connects to aconsole PC 24 through a connecting bus 26. The console PC 24 is used formaintenance and access to the controller 16 and can be employed to setparameters of the controller 16 as is well known in the art.

[0021] The controller may be connected to a remote data processingsystem like the data processing system 10 or a remote data storagesystem like the data storage system 14 (shown in dashed lines) for databack-up capability by a data link 28. The data link 28 is implementedaccording to Gigabit Ethernet protocols. Other network protocols can beused as well. The data link 28 enables a remote data storage system tostore on its own devices a copy of information stored in the devices 18of the data storage system 14 in a mirrored manner, as will bedescribed.

[0022] In operation, the host computers 12 a, 12 b, . . . , 12 m, send,as required by the applications they are running, commands to the datastorage system 14 requesting data stored in the logical volumes orproviding data to be written to the logical volumes. Referring to FIG.2, and using the controller in the Symmetrix data storage system as anillustrative example, details of the internal architecture of the datastorage system 14 are shown. The communications from the host computer12 typically connect the host computer 12 to a port of one or more hostdirectors 30 over the SCSI bus lines 20. Each host director, in turn,connects over one or more system buses 32 or 34 to a global memory 36.The global memory 36 is preferably a large memory through which the hostdirector 30 can communicate with the disk devices 18. The global memoryincludes a common area 38 for supporting communications between the hostcomputers 12 and the disk devices 18, a cache memory 40 for storing dataand control data structures, and tables 42 for mapping areas of the diskdevices 18 to areas in the cache memory 40.

[0023] Also connected to the global memory 36 are back-end (or disk)directors 44, which control the disk devices 18. In the preferredembodiment, the disk directors are installed in the controller 16 inpairs. For simplification, only two disk directors, indicated as diskdirectors 44 a and 44 b, are shown. However, it will be understood thatadditional disk directors may be employed by the system.

[0024] Each of the disk directors 44 a, 44 b supports four bus ports.The disk director 44 a connects to two primary buses 22 a and 22 b, aswell as two secondary buses 22 a′ and 22 b′. The buses are implementedas 16-bit wide SCSI buses. As indicated earlier, other bus protocolsbesides the SCSI protocol may be used. The two secondary buses 22 a′ and22 b′ are added for redundancy. Connected to the primary buses 22 a, 22b, are the plurality of disk devices (e.g., disk drive units) 18 a and18 b, respectively. The disk director 44 b connects to two primary buses22 c and 22 d. Connected to the primary buses 22 c, 22 d are theplurality of disk devices or disk drive units 18 c and 18 d. Alsoconnected to the primary buses 22 c and 22 d are the secondary buses 22a′ and 22 b′. When the primary bus is active, its correspondingsecondary bus in inactive, and vice versa. The secondary buses of thedisk director 44 b have been omitted from the figure for purposes ofclarity.

[0025] Like the host directors 20, the disk directors 44 are alsoconnected to the global memory 36 via one of the system buses 32, 34.During a write operation, the disk directors 44 read data stored in theglobal memory 36 by a host director 30 and write that data to thelogical volumes for which they are responsible. During a read operationand in response to a read command, the disk directors 44 read data froma logical volume and write that data to global memory for later deliveryby the host director to the requesting host computer 12.

[0026] As earlier mentioned, the data storage system 14 can be remotelycoupled to another data storage system 14 in a mirrored storageconfiguration, using the data link 28. Still referring to FIG. 2, eachdata storage system 14 in the mirrored storage configuration includes aremote director 48 to connect to the data link 28 and handle transfersof data over that link. The remote director 48 communicates with theglobal memory 36 over one of the system buses 32, 34.

[0027] Referring to FIG. 3, a remote data services (e.g., datamirroring) storage configuration 50 includes two or more of the datastorage systems 14 (illustrated as three data storage systems 14 a, 14 band 14 c). The data storage systems 14 a, 14 b and 14 c are directlycoupled to an IP network (shown as the Internet 52) by respective datalinks 28 a, 28 b and 28 c. The data links 28 are implemented as GigabitEthernet transmission channels as mentioned earlier, but any suitabletransmission medium for supporting TCP/IP traffic may be used. The datalinks 28, and the IP network 52, are used to support connections forcarrying TCP/IP traffic between the units 14. For example, a firstconnection 54 a may be established between the data storage systems 14 aand 14 b. A second connection 54 b may be established between the datastorage systems 14 b and 14 c. A third connection 54 c may beestablished between the data storage systems 14 c and 14 a. In thesystem 50, the data storage systems 14 are configured for remote datamirroring capability. More specifically, in the example shown, there areeight device groups, S1, S2, S3, S4, T1, T2, T3, T4, which are indicatedby reference numerals 56 a, 56 b, 56 c, 56 d, 56 e, 56 f, 56 g, 56 h,respectively. Four of the device groups, SI through S4, are sourcedevice groups, and device groups T1 through T4 are target device groups.In the example shown, the data storage systems 14 are configured in thefollowing manner: the data storage system 14 a supports device groupsSI, S2 and T3; the data storage system 14 b supports device groups S4,T1 and T2; and the data storage system 14 c supports the device groupsS3 and T4. Thus, the devices in the source group SI are mirrored in thedevices in corresponding target device group T1, devices in the sourcegroup S2 are mirrored in the devices in corresponding target devicegroup T2, and so forth. Thus, the units use TCP/IP to exchange storagetraffic as required by remote data facility services, for example, thedata storage systems 14 a and 14 b establish a connection with eachother so that the data storage system 14 a can provide a copy of dataresiding on the source device group S1 to the target device group T1.Thus, the architecture of the remote directors 48 (as will be described)in the each of the data storage systems 14 allows those systems to usethe Internet infrastructure for disaster recovery and other remote dataservices. Although the IP network 52 is shown as the public Internet, itcould instead be a private network.

[0028] As shown in FIG. 4, the remote director 48 includes an RDFdirector 60 and a link director 62. The RDF director 60 includes aprocessor 64 coupled to a local, nonvolatile memory (NVM) 66. The NVM 66includes a control store 68 and a parameter store 70. The link director62 includes a processor 72 coupled to its own, NVM 74, which alsoincludes a control store 76 and a parameter store 78. The directors 60,62 each have access to a shared memory 80. The processor 64 controls theoverall operations of the RDF director 62 and communications with thememories 66 and 80. The control store 68 stores firmware (or microcode)82 and parameter store stores parameter data, both of which are readeach time the data storage system 14 is initialized. The microcode 82 iscopied into the control store 68 at initialization for subsequentexecution by the processor 64. The processor 72 controls the overalloperations of the link director 62 and communications with the memories74 and 80. The control store 76 stores link firmware (or microcode) 84and the parameter store 78 stores parameter data, both of which are readeach time the data storage system 14 is initialized. The microcode 84 iscopied into the control store 76 at initialization for subsequentexecution by the processor 72.

[0029] Referring to FIG. 5, the microcodes 82 and 84 are shown. The RDFdirector's microcode 82 includes an RDF emulation layer 94, a CommonDevice Interface 96 and a first socket relay layer 98. The microcode 84,executed by the link processor 72, includes a second socket relay layer100, a TCP/IP layer 102 and a network driver 104. Collectively, thesocket relays 98, 100 represent a socket interface 108, and pass socketmessages to each other. Although the interface 108 between thehigher-level RDF emulation/CDI layers (which execute on the emulationprocessor 64) and the TCP/IP protocols of layer 102 (which execute onthe link processor 74) is shown as being implemented as a socketinterface, other interfaces could be used for communications between theRDF emulation and the TCP/IP protocols software.

[0030] The RDF emulation 94 can include the following: a system callslayer 110; advanced functionality modules 112, which may be optional atthe director level or even at the data storage system level; commonfunction modules 114, which are provided to each director in thecontroller 16; and an interface (director application) module. Interfacemodules exist for each of the different types of directors that areavailable based on connectivity and/or function, for example, a RemoteData Facility (RDF) interface defines the functionality of the remotedirector 48, mainframe and Open Systems host interfaces, respectively,define host directors 30, and a back-end interface defines thefunctionality of the back-end director 44.

[0031] The emulation is defined as software that implements both anUpper Level Protocol (ULP), that is, a protocol associated withfunctionality in one or more of layers 110, 112 and 114 (from FIG. 5),and functions corresponding to the RDF interface 116. Thus, theemulation 94 resides above any physical transport layers and includessoftware corresponding to the RDF interface 114 as well as softwareimplementing a ULP.

[0032] The CDI 96 recognizes that different physical transports havedifferent physical formats, data capacities and access characteristics.Consequently, the CDI 96 accommodates and isolates those physicaltransport differences so that those portions of the drivers andemulations that interact with each other are generic in nature. The CDI96 provides for versatility and is intended to support any existing orenvisioned transport functionality (or protocol). In addition toabstracting the details of different physical transport protocols, theCDI handles physical data movement (e.g., via a DMA mechanism, asdescribed below) and makes that data movement transparent to emulationsoftware.

[0033] The CDI can be viewed as being embodied in an I/O control block(hereinafter, “IOCB”) data structure. This IOCB data structure is ageneric structure that serves to define a common interface between theemulation 94 and a CDI compliant lower layer (CDI driver) with which theemulation 94 communicates in transferring commands and data. To make arequest (containing a ULP command) to a CDI driver, the RDF emulation 94uses a call, ‘CDI IOCTL’ that takes as its only parameter a pointer toan IOCB describing the request. During the lifetime of that request andits associated IOCB, the control of the IOCB alternates between theemulation and the CDI driver that has accepted it. The CDI driver hascontrol of the IOCB while an IOCTL call is outstanding. The RDFemulation 94 has control of the IOCB when the call request has beencompleted. Notification of events, e.g., the completion of an IOCTL callor the arrival of a new ULP command, is signaled by the CDI driver tothe emulation by placing corresponding IOCBs on queues referred toherein as event (or completion) queues. Thus, the emulation detects acall request completion status when it determines that the IOCBassociated with the call has been placed on an event queue by the CDIdriver. By removing the IOCB from the event queue, the emulation gainscontrol of the buffer that had been allocated to that IOCB.

[0034] The CDI 96 may be supported in a polled or interrupt drivenenvironment. In a polled environment, the emulation must make periodiccalls to a routine that acts as an interrupt service routine in that isgives the driver a chance to look at the physical interface and processany accumulated events. This call must be made frequently to facilitatethe timely discovery of new events or the completion of requests. In aninterrupt driven environment, interrupts allows events to be processedas they occur.

[0035] Further architectural and implementation-specific details of theCDI 96 can be found in co-pending U.S. patent application Ser. No.09/797,347, filed Mar. 1, 2001, incorporated herein by reference.

[0036] Still referring to FIG. 5, below the CDI 96 is the socketinterface 100. In the described embodiment, the RDF emulation 94 and thesocket interface 100 have knowledge of the CDI format. Thus, the CDI 96serves to isolate the RDF emulation 94 from the TCP/IP layer.

[0037] Implementation-specific details of the TCP/IP layer 102, as wellas lower network layers 104, 106 are implemented in known fashion andtherefore described no further herein. It will be appreciated that oneskilled in the art would be able to implement the required linkprocessor software (as well as any special hardware assists, e.g., DMA,not shown) necessary to transfer and receive packets over a GigabitEthernet data link using TCP/IP.

[0038] Although FIG. 5 shows the link processor firmware 84 as includingnetwork (e.g., Gigabit Ethernet) driver and hardware interface software(layers 104, 106), it will be appreciated that one or both of theselayers could be implemented in a separate, commercially availableGigabit MAC device or chipset.

[0039] Referring to FIG. 6, a conceptual depiction of the interface 48that shows some details of the shared memory 80 used for passing socketmessages between the emulation processor 64 and the link processor 72 isshown. The shared memory 80 includes data structures for messages 120and data 122, respectively. The messages are message related toestablishing and tearing down individual TCP/IP connections. The data isthe data to be encapsulated in a TCP/IP protocol data unit and passeddown the protocol stack for processing and transmission over the GigabitEthernet data link, or data that was received over the link anddecapsulated/processed as it is passed up the protocol stack in knownfashion. The message data structures include outgoing and inbound datastructures, 120 a and 120 b, for outgoing and inbound messages,respectively. Likewise, the data structures for managing transfer ofdata also include an outgoing data structure 122 a and an inbound datastructure 122 b. All of the structures 120 a, 120 b 122 a, 122 b may beimplemented as the same type of data structure, for example, circularrings.

[0040] It will be appreciated that the director 48 has been implementedas a two-processor architecture for performance reasons, that is, to offload the processing intensive TCP/IP operations from the processor thathandles the RDF interface to the link processor. However, a singleprocessor solution is also contemplated.

[0041] In addition, while the embodiment described above passes socketmessages across the two-processor boundary, it may be possible to splitthe CDI between processors so that the messages that are passed betweenprocessors are CDI messages instead of socket messages. Such animplementation would require that the TCP/IP layer have knowledge of andbe coded to conform to the CDI.

[0042] It is to be understood that while the invention has beendescribed in conjunction with the detailed description thereof, theforegoing description is intended to illustrate and not limit the scopeof the invention, which is defined by the scope of the appended claims.Other embodiments are within the scope of the following claims.

What is claimed is:
 1. In a remote data mirroring arrangement of datastorage systems, a method of operating a data storage system comprises:determining that storage traffic is to be transferred between the datastorage system and a remote data storage system to which the datastorage system is coupled by an IP network in accordance with a remotedata service application; and enabling transfer of the storage trafficbetween the data storage system and the remote data storage system overthe IP network using a native connection to the IP network.
 2. Themethod of claim 1, wherein the IP network is the Internet.
 3. The methodof claim 1, wherein the IP network is a private network.
 4. The methodof claim 1, wherein enabling comprises using a socket interface tointerface an operation of the remote data service to TCP/IP protocols.5. The method of claim 4, wherein the native connection comprises TCP/IPover Gigabit Ethernet
 6. The method of claim 5, wherein the socketinterface is split across two processors, with a first socket relayresiding on a first processor and a second socket relay residing on asecond processor.
 7. The method of claim 6, wherein the first socketrelay and remote data service application operation conform to a commoninterface.
 8. The method of claim 4, wherein enabling further comprisesusing the socket interface to create a socket from which the nativeconnection to the IP network is formed.
 9. A computer program productresiding on a computer-readable medium for operating a data storagesystem in a remote data mirroring arrangement of data storage systems,the computer program product comprising instructions causing a computerto: determine that storage traffic is to be transferred between the datastorage system and a remote data storage system to which the datastorage system is coupled by an IP network; and enable transfer of thestorage traffic between the data storage system and the remote datastorage system over the IP network using a native connection to the IPnetwork.
 10. A data storage system comprising: one or more storagedevices; a controller coupled to the one or more storage devices; andwherein the controller directs local storage traffic from the datastorage system to a remote data storage system over an IP network usinga native connection to the IP network.